When we have errors reported, can we not use exceptions and stack traces? I would prefer a severe message containing the class requiring the injection point, field name, and expected type. That will be easier than reading stacktraces.

The runtime won't boot in the case a dependency or a mandatory config setting is not satisfied, so an exception is perfectly fine, and the information you mentioned is indeed logged. In addition, changing the way dependency errors are reported would impact areas of code outside of the scope of this DR, so that would be a separate discussion anyway. My goal here was to align the error reporting of config injection with that of dependency injection.

When we have errors reported, can we not use exceptions and stack traces? I would prefer a severe message containing the class requiring the injection point, field name, and expected type. That will be easier than reading stacktraces.

The runtime won't boot in the case a dependency or a mandatory config setting is not satisfied, so an exception is perfectly fine, and the information you mentioned is indeed logged. In addition, changing the way dependency errors are reported would impact areas of code outside of the scope of this DR, so that would be a separate discussion anyway. My goal here was to align the error reporting of config injection with that of dependency injection.

That's not what I'm saying. When the missing config error is encountered, it should be reported to a context where it is collated, the loading for that extension is aborted, and loading then continues. After the phase is complete, the context should be checked, and the recorded errors (not exception) reported to the monitor. After the errors are reported, an exception can be thrown (or the runtime terminated).

That's not what I'm saying. When the missing config error is encountered, it should be reported to a context where it is collated, the loading for that extension is aborted, and loading then continues. After the phase is complete, the context should be checked, and the recorded errors (not exception) reported to the monitor. After the errors are reported, an exception can be thrown (or the runtime terminated).

how could loading continues if an extension is aborted? other extensions could be dependent of that one so likely other kind of errors could appear.
As it is done for @Injection points, it should fail at the first inconsistency

That's not what I'm saying. When the missing config error is encountered, it should be reported to a context where it is collated, the loading for that extension is aborted, and loading then continues. After the phase is complete, the context should be checked, and the recorded errors (not exception) reported to the monitor. After the errors are reported, an exception can be thrown (or the runtime terminated).

how could loading continues if an extension is aborted? other extensions could be dependent of that one so likely other kind of errors could appear. As it is done for @Injection points, it should fail at the first inconsistency

The point of this is to collate all missing configuration points. This may need to perform config injection before service injection to achieve that. During config injection, if there are errors, all operations on the extension in question should cease and the booter moves to the next extension.